Systems and methods for supporting transaction recovery based on a strict ordering of two-phase commit calls

ABSTRACT

Systems and methods are provided for supporting transaction recovery based on a strict ordering of two-phase commit calls. At least one resource manager in a mid-tier transactional environment can be designated as the “determiner resource,” in order to support eliminating mid-tier transaction logs (TLOG) in processing a two-phase transaction. A transaction manager can prepare all other resource managers in the mid-tier transactional system before the determiner resource. Furthermore, the transaction manager can rely on the list of outstanding transactions to be committed that is provided by the determiner resource for recovering the transaction. The transaction manager can commit an in-doubt transaction returned from a resource manager that matches the list of in-doubt transactions returned from the determiner resource. Otherwise, the transaction manager can roll back the in-doubt transaction.

CLAIM OF PRIORITY

This application claims priority on U.S. Provisional Patent ApplicationNo. 61/612,144, entitled “SYSTEM AND METHOD FOR PROVIDING DISTRIBUTEDTRANSACTION PROCESSOR DATABASE AFFINITY AND DISTRIBUTED TRANSACTIONPROCESS OPTIMIZATION,” by inventors Todd Little, Edward A. Heeren, PaulParkinson, Carol L. Colrain, Nancy Ikeda, Peizhi Shi, Right Lv, Jim Jinand Xugang Shen, filed Mar. 16, 2012 (Attorney Docket No.ORACL-05314US0), and U.S. Provisional Patent Application No. 61/774,356,entitled “SYSTEMS AND METHODS FOR SUPPORTING TRANSACTION RECOVERYWITHOUT TRANSACTION LOGS (TLOGS),” by inventors Paul Parkinson, Todd J.Little, Stefan Heinrich Roesch, Carol L. Colrain, Edward A. Heeren,filed Mar. 7, 2013 (Attorney Docket No. ORACL-05421US2), whichapplications are herein incorporated by reference.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is related to the following patent application, whichis hereby incorporated by reference in its entirety:

U.S. Patent Application titled “SYSTEMS AND METHODS FOR SUPPORTINGINLINE DELEGATION OF MIDDLE-TIER TRANSACTION LOGS TO DATABASE”,application Ser. No. __/______, filed ______, 2013 (Attorney Docket No.ORACL-05421US0).

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

FIELD OF INVENTION

The present invention is generally related to computer systems andsoftware such as middleware, and is particularly related totransactional middleware.

BACKGROUND

A transactional middleware system, or transaction oriented middleware,includes enterprise application servers that can process varioustransactions within an organization. With the developments in newtechnologies such as high performance network and multiprocessorcomputers, there is a need to further improve the performance oftransactional middleware. These are the generally areas that embodimentsof the invention are intended to address.

SUMMARY

Systems and methods are provided for supporting transaction recoverybased on a strict ordering of two-phase commit calls. At least oneresource manager in a mid-tier transactional environment can bedesignated as the “determiner resource,” in order to support eliminatingmid-tier transaction logs (TLOG) in processing a two-phase transaction.A transaction manager can prepare all other resource managers in themid-tier transactional system before the determiner resource.Furthermore, the transaction manager can rely on the list of outstandingtransactions to be committed that is provided by the determiner resourcefor recovering the transaction. The transaction manager can commit anin-doubt transaction returned from a resource manager that matches thelist of in-doubt transactions returned from the determiner resource.Otherwise, the transaction manager can roll back the in-doubttransaction.

Other objects and advantages of the present invention will becomeapparent to those skilled in the art from the following detaileddescription of the various embodiments, when read in light of theaccompanying drawings.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows an illustration of a transactional environment, inaccordance with an embodiment of the invention.

FIG. 2 shows an illustration of supporting two-phase commit in atransactional middleware machine environment.

FIG. 3 shows an illustration of recovering in-doubt transactions in atransactional middleware machine environment.

FIG. 4 shows an illustration of supporting a strict ordering oftwo-phase commit (2PC) calls for processing a transaction in atransactional middleware machine environment, in accordance with anembodiment of the invention.

FIG. 5 shows an illustration of recovering a global transaction withoutusing a transaction log (TLOG), in accordance with an embodiment of theinvention.

FIG. 6 is an illustrative flow chart of recovering a two-phase committransaction without using a transaction log (TLOG), in accordance withan embodiment of the invention.

DETAILED DESCRIPTION

The invention is illustrated, by way of example and not by way oflimitation, in the figures of the accompanying drawings in which likereferences indicate similar elements. It should be noted that referencesto “an” or “one” or “some” embodiment(s) in this disclosure are notnecessarily to the same embodiment, and such references mean at leastone.

The description of the invention as following uses the Tuxedoenvironment as an example for a transactional middleware machineenvironment. It will be apparent to those skilled in the art that othertypes of transactional middleware machine environments can be usedwithout limitation.

Described herein are systems and methods for supporting transactionrecovery based on a strict ordering of two-phase commit calls. At leastone resource manager in a mid-tier transactional environment can bedesignated as the “determiner resource,” in order to support eliminatingmid-tier transaction logs (TLOG) in processing a two-phase transaction.A transaction manager can prepare all other resource managers in themid-tier transactional system before the determiner resource.Furthermore, the transaction manager can rely on the list of outstandingtransactions to be committed that is provided by the determiner resourcefor recovering the transaction. The transaction manager can commit anin-doubt transaction returned from a resource manager that matches thelist of in-doubt transactions returned from the determiner resource.Otherwise, the transaction manager can roll back the in-doubttransaction.

A Transactional Environment and Global Transaction

FIG. 1 shows an illustration of a transactional environment, inaccordance with an embodiment of the invention. As shown in FIG. 1, atransactional environment 100 can include an end user 101, anapplication program 102, one or more transaction managers (TM) 103, aplurality of resource managers (RM) 104-106, and one or more persistencestores, e.g. the database 110.

In accordance with one embodiment of the invention, the applicationprogram 102 can specify actions that constitute a transaction. Asillustrated, the application program 102 communicates with thetransaction manager 103 to begin, commit, or abort a transaction, andthe transaction manager 103 can send back the start, end and dispositionof the transaction to the application program 102. Furthermore, theapplication program 102 can define transaction boundaries for thetransaction manager 103, which can exchange transaction information withthe plurality of resource managers (RM) 104-106. In addition, theapplication program 102 can communicate with the plurality of resourcemanagers 104-106 via Embedded Structured Query (SQL) to do useful work.

The plurality of resource managers 104-106 can provide access topersistence stores, e.g. the database 110. In accordance with anembodiment of the invention, the plurality of resource managers 104-106can implement XA interfaces to handle database connections anddisconnections transparently to persistence stores. The XA interfacescan be based on a specification that describes the protocol fortransaction coordination, commitment, and recovery. An XA resourceparticipating in a transaction can comprise an XA resource manager and abackend persistence store.

In accordance with various embodiments of the invention, a transactionalsystem can support a global transaction, which can be executed on morethan one server, and is capable of accessing data from more than oneresource manager.

A global transaction can be treated as a specific sequence of operationsthat are characterized by the four properties of atomicity, consistency,isolation, and durability (ACID). The global transaction can be alogical unit of work that has the following features:

-   -   All portions either succeed or have no effect.    -   Operations are performed that correctly transform the resources        from one consistent state to another.    -   Intermediate results are not accessible to other transactions,        although other processes in the same transaction may access the        data.    -   All effects of a completed sequence cannot be altered by any        kind of failure.

Furthermore, a global transaction may include several localtransactions, each accessing a single resource manager. A localtransaction can access a single database or file and can be controlledby the resource manager responsible for performing concurrency controland atomicity of updates at that distinct database. A given localtransaction may be either successful or unsuccessful in completing itsaccess.

Additionally, the transaction manager 103 can assign global transactionidentifiers (GTRIDs) to the different transactions in transactionalenvironment 100. The transaction manager 103 can monitor their progress,and take responsibility for ensuring transaction completion andproviding failure recovery. In addition, the transaction manager 103 cancommunicate with the plurality of resource managers 104-105 via XAinterfaces to exchange transaction information, such as sendingtwo-phase commits calls to the resource managers 104-105.

Two-phase Commit (2PC)

A two-phase-commit (2PC) protocol can be used to execute a transaction,such as a loosely-coupled global transaction. The two-phase-commitprotocol (2PC) can include a prepare phase and a commit phase. In theprepare phase, a coordinating transaction manager (TM) instructs theparticipating resource managers (RMs) to take the necessary steps foreither committing or aborting the transaction. In the commit phase, thetransaction manager (TM) decides whether to commit or abort thetransaction, based on the results of the prepare phase.

FIG. 2 shows an illustration of supporting two-phase commit in atransactional middleware machine environment. As shown in FIG. 2, atransactional environment 200 can include a transaction manager 201 thatsupports the execution of various transactions, and one or more resourcemanagers 202-204 that manage one or more data source, e.g. a database205.

For example, the transaction manager 201 can execute a transaction thatinvolves transaction branch A 211, transaction branch B 212, andtransaction branch C 213, each of which can be executed against aresource manager 202-204 respectively. If any branch fails in thetransaction, the transaction manager 201 can help the resource manager202-204 decide whether to commit, or roll back, the transaction.

As shown in FIG. 2, the transaction manager 201 can send a prepareinstruction to the resource manager 202-204 on all three branches (steps1, 2, and 3). After the resource managers 202-204 return an “OK” vote(steps 4, 5 and 6), the transaction manager 201 can write a transactionlog to the database 205 (step 7).

The transaction log (TLOG) may be written either to files, or to adatabase, so that the transaction manager 201 can have enoughinformation to recover the transaction if any branch fails during thecommit phase.

Then, the transaction manager 201 can instruct the resource manager202-204 to commit all three branches (steps 8, 9 and 10). The resourcemanager 202-204 can inform the transaction manager 201 aftersuccessfully completing the commit phase (steps 11, 12 and 13).

Transaction Recovery Based on a Transaction Log (TLOG)

In accordance with one embodiment of the invention, a transaction log(TLOG) can hold the decisions for committing transactions by atransaction manager. For example, the TLOG can store a resourcecheckpoint record, which can be persisted by the transaction manager toenable it to track the different participating XA resources.

A transaction can be written in the TLOG when a transaction managerreceives a success vote from all transaction branches after the preparephase. The transaction record in TLOG can include at least a transactionidentifier (XID), which further includes a GTRID assigned by atransaction manager, and a local XID assigned by a resource managerwhere the transaction is executed.

Furthermore, the TLOG can hold records of the state of in-flighttransactions that are marked to be committed. The TLOG is beneficial torecover in-doubt transactions, which are the transactions that have beenprepared but have not yet been committed in a mid-tier transactionalsystem, after a system crash. Without recovering the in-doubttransactions, the system can be in an incorrect and inconsistent stateafter a crash.

For example, if a system fails during a two-phase commit transaction,the updates to one backend data store may have committed, but theupdates to another data store, in the same transaction, may not yet havebeen instructed to commit, i.e. the data store's updates are stillpending. Once the failed parts of the system have been re-started, thedata stores holding pending updates may not be able to know whether theupdates should be committed or rolled-back.

FIG. 3 shows an illustration of recovering in-doubt transactions in atransactional middleware machine environment. As shown in FIG. 3, thetransactional middleware machine environment 300 includes a transactionmanager 301, and a plurality of resource managers 302-304, and apersistence store, i.e. a database 305.

The transaction manager 301 can automatically determine whether a globaltransaction is in-doubt, by reading the TLOG (step 1). Then, thetransaction manager 301 can poll the relevant backend data stores of theparticipating resource managers 302-304. Each of the participatingresource managers 302-304 can return a list of in-doubt transactions,which are the transactions that the transaction manager 301 does notknow whether to roll it back or commit (steps 2, 4 and 6).

Furthermore, the transaction managers 301 can match each in-doubttransaction with the TLOG, and proceed to either commit or roll back thein-doubt transactions on different resource managers 302-304 (steps 3, 5and 7). For example, when an in-doubt transaction appears in the TLOG,an XAResource.commit( ) can be called to commit the in-doubt transactionto a resource manager specified in the TLOG. On the other hand, when atransaction is not in the TLOG, i.e. a commit decision has not been madeon the transaction before a crash, an XAResource.rollback( ) can becalled to roll it back on a resource manager based on the transactionidentifier (XID).

As shown in FIG. 3, a transaction may have been prepared on a resourcemanager 302 and the system crashes before the resource manager 302 cansend the success vote to the transaction manager 301. Then, thetransaction manager 301 may not be able to receive a success vote fromall transaction branches, and therefore can not log the transaction inthe TLOG. Accordingly, the transaction manager 301 can roll back allbranch transactions on their respective resource managers 302-304. Thus,using such a consistent and predictable transaction recovery approach, atransaction manager can avoid a mixed heuristic completion where somebranches are committed and some are rolled back.

Alleviating the Need for Transaction Manager Recovery Logs

In a transactional environment, recovery information can be persisted tostable storage in order to conduct recovery and ensure ACID propertiesis a design requirement of two-phase commit transaction managers.

For example, the (XA) two-phase logging algorithm can involve thefollowing steps:

-   -   1. The application uses multiple XA resources in a transaction        and issues commit for the transaction.    -   2. The transaction manager issues XAResource.prepare on all XA        resource participants.    -   3. The transaction manager persists a transaction log which        contains the format id and global transaction id of the        transaction.    -   4. The transaction manager issues XAResource.commit on all the        XA resource participants.    -   5. The transaction manager (generally lazily, in batches, etc.)        purges/deletes the transaction record.    -   6. In the event of failure, the persisted transaction records        are matched to the in-doubt Xids returned from        XAResource.recover calls made on all involved resource managers        and recovery by commit or rollback is conducted accordingly.

The need to persist recovery information to stable storage, alongsidethe actual protocol network calls to resource managers, can inflictperformance cost for two-phase commit transactions. It can also carryasset capacity cost due to the shared file system or database storagenecessary for highly-available stable storage as well as administrativecost due to the management of this storage. These costs may escalate inthe case of site-wide disaster recovery where (synchronous) replicationand again management of the same are required. Thus, alleviating theneed for transaction manager recovery logs can provide a significantimprovement over existing systems.

In accordance with one embodiment of the invention, using the followingtechnique, it is possible to alleviate the need for transaction logs byproviding transaction recovery and ACID properties based on strictordering of two-phase commit calls and the classification of oneresource participant as the determiner of recovery:

-   -   1. The application uses multiple XA resources in a transaction        and issues commit for the transaction.    -   2. Certain resources can be configured to be designated as the        “determiner” of transaction outcomes. If no such resource is        configured the transaction system will nominate one and persist        this in configuration.    -   3. Whenever a resource is first used or a new combination of        resources is first used in a two-phase transaction, this        combination is captured and persisted in configuration        automatically by the transaction processing subsystem. This        configuration persistence occurs just before the first prepare        issued for such a transaction. If this configuration change        fails the transaction can be rolled back. While not necessary,        this step provides further optimization as it reduces the set of        resources that require XAResource.recover calls during recovery.    -   4. The transaction manager forgoes any transaction logging.    -   5. The transaction manager issues XAResource.prepare on all XA        resource participants, preparing the “determiner” resource last.    -   6. The transaction manager issues XAResource.commit on all XA        resource participants, committing the “determiner” resource        last.    -   7. In the event of failure, a XAResource.recover scan is        conducted on all non-“determiner” resources in configuration and        the in-doubt Xids are matched to the in-doubt Xids returned from        the determiner resource's XAResource.recovery. Recovery by        commit if there is a match/existing Xid in the determiners list        or by rollback if there isn't is conducted accordingly.    -   8. During a clean shutdown or restart of the transaction system        the configuration is purged/marked in such a way that        unnecessary recover calls and processing are not conducted        during startup.

The above-mentioned technique can be described in more details in thefollowing sections.

A Strict Ordering of the Two-phase Commit (2PC) Calls

In accordance with an embodiment of the invention, the system caneliminate mid-tier transaction logs (TLOGs) in processing a transaction,based on a strict ordering of the two-phase commit calls.

FIG. 4 shows an illustration of supporting a strict ordering oftwo-phase commit (2PC) calls for processing a transaction in atransactional middleware machine environment, in accordance with anembodiment of the invention. As shown in FIG. 4, a global transaction410 can be supported in a mid-tier transactional system 400 thatincludes a transaction manager (TM) 401, a plurality of resourcemanagers (RMs) 402-404. The resource managers (RMs) 402-403 participatein the global transaction 410, and the resource manager 404 does notparticipate in the global transaction 410. In accordance with anembodiment of the invention, the transaction 410 does not span multipletransactional managers.

The transaction manager 401 can designate a resource, e.g. the resourcemanager (RM) 402 that is associated with the database 405, as thedeterminer resource (step 1). The designation of the resource manager(RM) 402, as the determiner resource, can be persisted in theconfiguration for the transaction machine environment. When nodeterminer resource is designated in a transaction in configuration, thetransaction manager 401 can nominate a data source as the determinerresource and persist it in the configuration. Additionally, thedeterminer resource 402 can be a resource other than a database, such asa message queue.

Furthermore, whenever a resource is first used or a new combination ofresources is first used in processing the two-phase transaction 410, thenew resource or the new combination of resources can be captured andpersisted in the configuration, such as a configuration file,automatically by the transaction manager 401. This configurationpersistence can occur right before the first prepare request is issuedfor the two-phase transaction. If this configuration change fails, thetransaction 410 can be rolled back.

In accordance with an embodiment of the invention, the transactionmanager 401 can ensure that the determiner resource, e.g. resourcemanager 402, to be the last prepared and committed among allparticipating resource managers, for a two phase transaction 410.

As shown in FIG. 4, the transaction manager 401 can first prepare theresource manager (RM) 403 (step 2), before preparing the determinerresource (step 4). After receiving a “Ok” vote from the participatingresource managers (RMs) 402-403 (steps 3 and 5), the transaction manager401 can commit the resource manager (RM) 403 (step 6), followed by thedeterminer resource (step 8). The transaction can be completed after thetransaction manager 401 receives a success indication from each of theresource managers 402-403 (steps 7 and 9).

Thus, the transaction manager 401 can forgo any logging ofresources/checkpoints, including writing a TLOG after the prepare phaseis handled successfully. The system can improve the performance of thetransaction, while allowing the mid-tier transactional system 400 torecover the transaction 410.

Recovering a Global Transaction without Using a TLOG

FIG. 5 shows an illustration of recovering a global transaction withoutusing a transaction log (TLOG), in accordance with an embodiment of theinvention. As shown in FIG. 5, a global transaction 510 can be supportedin a mid-tier transactional system 500 that includes a transactionmanager (TM) 501, a plurality of resource managers (RM) 502-504.

When the transaction 510 needs to be recovered, the transaction manager501 can attempt to recover, e.g. by placing an XA_recover( ) call, onthe determiner resource 502 (step 1). The transaction manager 501 canreceive a list of in-doubt transactions (prepared but not committedtransactions) from the determiner resource 502 (step 2). Furthermore,the transaction manager 501 can use the list of in-doubt transactions tobuild/rebuild the global transaction table (GTT 506) (steps 3).

In accordance with one embodiment of the invention, when the determinerresource 502 is successfully prepared in the two-phase committransaction, the list of in-doubt transactions can be identical tomid-tier outstanding transactions that the transaction manager 501 hasinstructed the participating resource managers 502-503 to commit.

Then, the transaction manager 501 can attempt to recover, e.g. byplacing an XA_recover( ) call, on all the other resource managers in thetransactional mid-tier system 500, including the participating resourcemanager 503 (step 9) and the non-participating resource manager 504(step 10).

For example, the transaction manager 501 can receive a list of in-doubttransactions from the participating resource manager 503 (step 5). Thetransaction manager 501 can match the in-doubt transactions in the listwith the GTT 506 table to generate a recover list (steps 6 and 7). Then,the transaction manager 501 can recover the participating resourcemanager 503 based on the recover list (step 8). For example, thetransaction manager 501 can commit the in-doubt transactions that matchthe GTT 506 table, and can roll back the in-doubt transactions that donot match the GTT 506 table.

The above procedures can be performed on the resource manager 504, whichis a non-participating resource. As illustrated in FIG. 5, after placingan XA_recover( ) call on the resource manager 504, the transactionmanager 501 can receive a list of in-doubt transactions (step 11), whichcan be matched with the GTT 506 to generate a recover list (step 12).Then, the transaction manager 501 can commit/rollback the in-doubttransactions on the resource manager 504 (steps 14 and 15).

Once all the other resource managers 503-504 are recovered (steps 9 and15), the transaction manager 501 can commit all transactions in the listof prepared transactions to the determiner resource manager (steps 16and 17). Finally, transaction manager 501 can remove the entries in theGTT 506 (step 18).

As described herein, no transaction from the list of in-doubttransactions can be committed to the determiner resource manager 502until all other resource managers 503-504 have been recovered, even ifone or more resource managers are not part of the transaction.

In one embodiment of the invention, the transaction manager 501 can haveknowledge of the participating resources 502, 503 of the transaction ifadditional information about the participating resources 502, 503 can bepassed along and persisted to the determiner resource 502 in the preparephase. With the additional information, the transaction manager 501 cancommit the transactions in the list of in-doubt transactions returnedfrom the determiner resource manager 502, without waiting for all knownresource managers 502-504 to recover. The transaction manager 501 mayonly need to wait until all participants of the transaction 502-503 arerecovered.

Additionally, during a clean shutdown or restart of the transactionalmid-tier system 500, the configuration can be purged or marked, in sucha way that unnecessary recovery and processing may be avoided duringstartup.

FIG. 6 is an illustrative flow chart of recovering a two-phase committransaction without using a transaction log (TLOG), in accordance withan embodiment of the invention. As shown in FIG. 6, at step step 601, atransaction manager can performs an XA_recover( ) call on the determinerresource and receives a list of outstanding transactions to be committedin a mid-tier transactional system. Then, at step step 602, thetransaction manager can use the list of prepared transactions to rebuildthe global transaction table (GTT) table. Next, at step step 603, thetransaction manager can perform an XA_recover( ) call on each of theother resource managers in the system, including participants ornon-participants of the transaction, and can receive a list of in-doubttransaction from each of the other resource managers. At the step 604,the transaction manager can recover each transaction from the lists ofin-doubt transactions by matching the transaction with the GTT table.The transaction can be committed to the resource manager from which thetransaction is retrieved if a match is found in the GTT table;otherwise, it can be rolled back. Finally, at step 605, the transactionmanager can commit the transactions in the in-doubt transactions fromthe determiner resource, after all the in-doubt transactions on theother resource managers are recovered.

The present invention may be conveniently implemented using one or moreconventional general purpose or specialized digital computer, computingdevice, machine, or microprocessor, including one or more processors,memory and/or computer readable storage media programmed according tothe teachings of the present disclosure. Appropriate software coding canreadily be prepared by skilled programmers based on the teachings of thepresent disclosure, as will be apparent to those skilled in the softwareart.

In some embodiments, the present invention includes a computer programproduct which is a storage medium or computer readable medium (media)having instructions stored thereon/in which can be used to program acomputer to perform any of the processes of the present invention. Thestorage medium can include, but is not limited to, any type of diskincluding floppy disks, optical discs, DVD, CD-ROMs, microdrive, andmagneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flashmemory devices, magnetic or optical cards, nanosystems (includingmolecular memory ICs), or any type of media or device suitable forstoring instructions and/or data.

The foregoing description of the present invention has been provided forthe purposes of illustration and description. It is not intended to beexhaustive or to limit the invention to the precise forms disclosed.Many modifications and variations will be apparent to the practitionerskilled in the art. The embodiments were chosen and described in orderto best explain the principles of the invention and its practicalapplication, thereby enabling others skilled in the art to understandthe invention for various embodiments and with various modificationsthat are suited to the particular use contemplated. It is intended thatthe scope of the invention be defined by the following claims and theirequivalence.

What is claimed is:
 1. A method for recovering a transaction on a plurality of resource managers, the method comprising: designating a resource manager in the plurality of resource managers to be a determiner resource, wherein the determiner resource maintains a list of outstanding transactions to be committed; retrieving a list of in-doubt transactions from each resource manager in the plurality of resource managers; and committing one or more in-doubt transactions in the list of in-doubt transactions on at least one said resource manager in the plurality of resource managers, wherein said one or more in-doubt transactions match the list of outstanding transactions to be committed as provided by the determiner resource.
 2. The method of claim 1, further comprising: rolling back one or more in-doubt transactions in the list of in-doubt transactions on at least one said resource manager in the plurality of resource managers, wherein said one or more in-doubt transactions can not match the list of outstanding transactions to be committed.
 3. The method of claim 1, further comprising: allowing the transaction to be a two-phase commit transaction.
 4. The method of claim 3, further comprising: persisting the determiner resource in a configuration for a transactional mid-tier system before performing a prepare phase in the two-phase commit transaction.
 5. The method of claim 1, further comprising: preparing the determiner resource after preparing all other resource managers in the plurality of resource managers; and committing the determiner resource after committing all other resource managers in the plurality of resource managers.
 6. The method of claim 5, further comprising: allowing at least one resource manager in the plurality of resource managers to be a non-participant of the transaction.
 7. The method of claim 1, further comprising: committing a list of in-doubt transactions returned from the determiner resource after recovering all other resource managers in the plurality of resource managers.
 8. The method of claim 1, further comprising: building/rebuilding a global transaction table (GTT) from a list of in-doubt transactions returned from the determiner resource; and comparing each in-doubt transaction with the GTT.
 9. The method of claim 1, further comprising: passing, to the determiner resource, a list of participant resource managers in the plurality of resource managers that are enlisted in the transaction.
 10. The method of claim 9, further comprising configuring the determiner resource to wait, before recovering, until the list of participant resource managers are recovered.
 11. A system for recovering a transaction, the system comprising: a transaction manager; and a plurality of resource managers that communicates with the transaction manager in a mid-tier transactional system, and wherein the transaction manager operates to perform the steps comprising: designating a resource manager in the plurality of resource managers to be a determiner resource, wherein the determiner resource maintains a list of outstanding transactions to be committed; retrieving a list of in-doubt transactions from each resource manager in the plurality of resource managers; and committing one or more in-doubt transactions in the list of in-doubt transactions on at least one said resource manager in the plurality of resource managers, wherein said one or more in-doubt transactions match the list of outstanding transactions to be committed as provided by the determiner resource.
 12. The system of claim 11, wherein: the transaction manager operates to roll back one or more in-doubt transactions in the list of in-doubt transactions on at least one said resource manager in the plurality of resource managers, wherein said one or more in-doubt transactions can not match the list of outstanding transactions to be committed.
 13. The system of claim 11, wherein: the transaction is a two-phase commit transaction.
 14. The system of claim 13, wherein: the transaction manager operates to persist the determiner resource in a configuration for a transactional mid-tier system before performing a prepare phase in the two-phase commit transaction.
 15. The system of claim 11, wherein: the transaction manager operates to perform the steps further comprising: preparing the determiner resource after preparing all other resource managers in the plurality of resource managers; and committing the determiner resource after committing all other resource managers in the plurality of resource managers.
 16. The system of claim 15, wherein: at least one resource manager in the plurality of resource managers is a non-participant of the transaction.
 17. The system of claim 11, wherein: the transaction manager operates to commit a list of in-doubt transactions returned from the determiner resource after recovering all other resource managers in the plurality of resource managers.
 18. The system of claim 11, wherein: the transaction manager operates to perform the steps further comprising: building/rebuilding a global transaction table (GTT) from a list of in-doubt transactions returned from the determiner resource; and comparing each in-doubt transaction with the GTT.
 19. The system of claim 11, wherein: the transaction manager operates to perform the steps further comprising: passing a list of participant resource managers in the plurality of resource managers that are enlisted in the transaction to the determiner resource, and configuring the determiner resource to wait, before recovering, until the list of participant resource managers are recovered.
 20. A non-transitory machine readable storage medium having instructions stored thereon that when executed cause a system to perform the steps comprising: designating a resource manager in a plurality of resource managers to be a determiner resource, wherein the determiner resource maintains a list of outstanding transactions to be committed; retrieving a list of in-doubt transactions from each resource manager in the plurality of resource managers; and committing one or more in-doubt transactions in the list of in-doubt transactions on at least one said resource manager in the plurality of resource managers, wherein said one or more in-doubt transactions match the list of outstanding transactions to be committed as provided by the determiner resource. 